With a database management system (DBMS), when it comes to searching data stored in database structures within and/or outside the system, the operator typically inputs search criteria into the DBMS, which extracts data that matches the search criteria entered. The data so extracted has its specific implication, one by one. Thus, attempts have been made to retain a collection of such data as a set and include that set in a search target as well, thereby facilitating efficient search processing.
When a set is stored, a name that reflects its implication is imparted to the set, or a memo or the like that describes an implication of the set is attached thereto, in order to recognize individual sets.
However, as the number of sets increases, such identification techniques become meaningless. For example, assuming that a search is conducted on items describing the number of employees of a company, then there are a great variety of sets, including: a set of medium-sized companies (having 50 through 500 employees); a set of small-sized companies (having 50 or less employees); a set of mom-and-pop companies (having four or less employees); a set of companies having four employees; a set of companies having three employees; a set of companies having three or four employees; a set of companies having one employee; and so forth. An actual search is typically conducted using search criteria across several items; as such, if a search criterion related to the “region”, for example, is merely added to the afore-described “number of employees”, the number of sets would increase unlimitedly, such as a set of companies of medium size (having 50 through 500 employees) and located in Tokyo; a set of companies of medium size (having 50 through 500 employees) and located in Kanagawa; a set of companies of medium size (having 50 through 500 employees) and located in Chiba; and so on.
In this way, it could become difficult to find a set of interest among enormous amounts of sets merely through names of sets or their memos, and even though it has been retained as an already searched set, it could no longer be searched quickly.
With techniques for identifying individual sets by names of sets or memos, etc., ones having identical implications but different names might be created unless names or memos are assigned by stringent rules; as a result, useless sets would be stored in redundancy.
In addition, there may be cases where sets having similar implications have to be retained in redundancy because search criteria are slightly different. In the afore-described example, the set of mom-and-pop companies (having four or less employees), the set of companies having four employees, the set of companies having three or four employees are overlapped in the sense that those are companies having four employees; however, because queries about the number of employees to be determined are different, they are separate sets from each other.
Furthermore, there are often cases where data on the same customer are managed according different concepts, such as sales data and repair data regarding a particular customer, or where data of exactly identical contents are managed under different code systems among database structures. In such cases, it is necessary to modify the system so as to have a unified code system, or to separately build an analytical system having a unified code system and import data into that analytical system.
Additionally, even though a desired result may be obtained more quickly by collecting and retaining search results as sets than not by collecting as sets, identification information alone that identifies each set element would not be enough for outputting a final search result.
For example, unless information, such as the name, address, telephone number, etc. of a customer identified by the identification information is appended in addition to the identification information before it is outputted, the resulting information would often be insufficient. In order to output such information, reference must be made separately to a database structure that records customer names, addresses, telephone numbers, and so forth. In other words, to utilize the sets, cooperation is required with the database structure that provides a basis for creating sets, when a search is conducted. Thus, search service may be requested during a period when the database structure is not operational due to its maintenance or for other reasons, or, because of its architecture, it cannot be applied to a search system that is not physically connected to the database structure.
Accordingly, it is an object of the present invention to provide a mechanism for enabling search and other operations on sets to be performed quickly by managing sets in an orderly fashion.